Works locally with latest chrome, but CI wasn't running with the previous PR, so let's see if this works in all browsers.

@alvinlindstam Looks like the storage events don't quite behave as expected in IE

@danielstjules Ah, in what way? I'd be happy to assist in fixing it if possible.

@alvinlindstam Here's a link to the job associated with your original PR: https://travis-ci.org/zendesk/cross-storage/builds/242063000 The squashed commit is here: 360b896

IE in particular is firing more events than intended. I can probably test against a VM some time next week.

Ah, I guess it's related to the known issues mentioned on https://caniuse.com/#feat=namevalue-storage.

The "storage" event is completely wrong in IE:
IE10 : The storage event is fired even on the originating document where it occurred. Causes problems with multiple windows websites, and huge problems with iframes.
IE11 : The storage event's oldValue and newValue are identical (newValue is supposed to contain the storage's updated value).

Partial workaround: regularly probe the storage's value and compare with the last known value on all pages where you want to listen to this event, and track the last submitted value to determine if the modification was triggered locally.

Should we try to use their suggested workaround or document the bugs? The same issues would occur if using vanilla localStorage on the same host with IE.

The workaround would be more difficult to do on the client side however, so if it should be worked around it should probably be on the hub side. But continuously polling and storing all key-value-pairs in localstorage could be quite a performance issue (mainly memory) depending on the stored data.

Is this feature still planned?

Regarding this:

continuously polling and storing all key-value-pairs in localstorage could be quite a performance issue (mainly memory) depending on the stored data.

Maybe this could be an opt-in feature so that this cost is not incurred unless you intend to use events?